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Abstract 

The control system (TICS) for the test interferometer being 
built to support the development of the Atacama Large Mil- 
limeter Array (ALMA)[[i| will itself be a prototype for the 
final ALMA array, providing a test for the distributed con- 
trol system under development. TICS will be based on the 
ALMA Common Software (ACS)[||] (developed at the Eu- 
ropean Southern Observatory), which provides CORBA- 
based[^[| services and a device management framework for 
the control software. 

Simple device controllers will run on single board com- 
puters, one of which (known as an LCU) is located at each 
antenna; complex, compound device controllers may run 
on centrally located computers. In either circumstance, 
client programs may obtain direct CORBA references to 
the devices and their properties. Monitor and control re- 
quests are sent to devices or properties, which then pro- 
cess and forward the commands to the appropriate hard- 
ware devices as required. Timing requirements are met by 
tagging commands with (future) timestamps synchronized 
to a timing pulse, which is regulated by a central reference 
generator, and is distributed to all hardware devices in the 
array. Monitoring is provided through a publish/subscribe 
CORBA-based service. 

1 ALMA 

The Atacama Large Millimeter Array, or ALMA, is a radio 
astronomy millimeter and sub-millimeter array to be built 
in Chile's Atacama desert (at an elevation of 5000m above 
sea level) in the coming years. The project is an interna- 
tional collaboration among partners from Europe, Japan, 
Canada, Chile, and the USA. Current plans are for an ar- 
ray consisting of sixty-four parabolic antennas of twelve 
meter diameter, with configurations ranging in size from a 
compact configuration, with a maximum baseline of 150 
m, to an extended configuration, with a maximum baseline 
of 10 km. Each of the antennas will contain from four to 
ten cryogenically cooled receivers, operating in the range 
from 3 1 GHz to 950 GHz. Science data will be digitized at 
each antenna, and transmitted via optical fiber to a central 
location at a rate of 3 GB/s per antenna. 



2 TEST INTERFEROMETER CONTROL 
SYSTEM: TICS 

Three antennas, one contracted by each of the high-level 
partners in the ALMA project, will be delivered over the 
next two years to the National Radio Astronomy Observa- 
tory's Very Large Array site in New Mexico. These anten- 
nas are collectively known as the Test Interferometer (TI). 
The TI will be used for comparative evaluations of the three 
products to assess which design will be used for the anten- 
nas in the final ALMA array. Simultaneously, the TI will 
also be employed as a test-bed for the development of tech- 
nologies to be used by the ALMA array; in particular, the 
development of the control system software for the ALMA 
project. Nonetheless, the primary goal of TICS is to pro- 
vide the TI itself with a comprehensive array control sys- 
tem. 

2.1 ALMA Common Software: ACS 

The common base of all software being developed for 
ALMA will be the ALMA Common Software (ACS). Most 
of the development of ACS is being done by the Euro- 
pean Southern Observatory, based in Garching, Germany. 
ACS provides a CORBA-based device management frame- 
work, system services, application services, and an appli- 
cation framework for all software that will be required for 
ALMA. TICS is the first application to use ACS, and has 
been developed roughly in parallel with ACS. The device 
management framework and system services have been the 
primary features used in the development of TICS to this 
point in time. Some of the ACS features employed by TICS 
include: 

• object lifetime management 

• configuration database (devices and properties) 

• naming service 

• time service. 

2.2 Control System Architecture 

At each antenna there is an Antenna Bus Master (ABM): a 
VME bus Power PC based computer running the VxWorks 
operating system. Its principal role is to provide real-time 
control of the devices at the antenna based upon infrequent 



time-tagged commands from the center. The ABM also 
serves as a router for an antenna Ethernet segment. 

Most devices with computer interfaces are attached to a 
Controller Area Network (CAN) bus, through which they 
are controlled and monitored by the ABM. 

Each ABM is connected to the central systems via a 
point-to-point Gigabit Ethernet network that terminates at 
a switch. The switch is in turn connected to a high-speed 
switched network on which all central ALMA computer 
systems required to operate the array are attached. 

Two real-time computers are situated at a central loca- 
tion of the array. The Array Real-Time Machine (ARTM) 
plays the role of the ABM at the central location, provid- 
ing local real-time control of its attached devices. The 
other central real-time computer, the Correlator Control 
Computer (CCC), provides the interface for the correlator, 
and detailed control of the correlator hardware. Both the 
ARTM and CCC are VME/PPC/VxWorks based systems. 

The coordination function is implemented via the Array 
Control Computer (ACC), which is a high-end workstation 
running the Linux operating system. It is responsible for 
controlling all hardware in the array (indirectly through the 
ABM, ARTM, and CCC computers) under the command 
of a high-level observing script. The ACC also runs var- 
ious ancillary software such as model servers (e.g., phase 
models), and data formatting. 

Almost all devices will be attached to a CAN bus operat- 
ing in a master/slave (polled) fashion. The bus will operate 
at 1 Mbps and is capable of at least 2000 polled operations 
per second (up to 8 bytes of data per transaction). Devices 
on the CAN bus will be responsible for implementing a 
simple in-house protocol to map CAN message IDs to in- 
ternal device addresses. A few devices will have other con- 
nections, in particular Ethernet. 

2.3 Devices 

Logically, the software is partitioned so that control flows 
in a master-slave fashion from a central executive, which 
controls high-level ("composite") software devices, which 
in turn control their constituent parts. The lowest level 
software devices are referred to as device controllers, and 
represent a proxy for the actual hardware — that is, they 
communicate with the hardware. Data, both monitor and 
back-end, are collected from the devices by a collecting 
process in the real-time computer connected to the hard- 
ware, and are then buffered up for distribution, via a pub- 
lish/subscribe mechanism, to data consumers. Standard 
data consumers include processes that format and archive 
the data. The software is distributed among the comput- 
ers so that only the device controllers and software directly 
concerned with low-level device activities are on the local 
real-time computer. All higher-level software entities are 
concentrated on the ACC. 

Engineering access to devices that are installed on the 
test interferometer will be implemented by access to the 
device controller interface, or to the I/O routines directly 



from engineering workstations. 

Naming services provided by ACS are used by clients 
to obtain CORBA references to the devices. Transient ser- 
vants are created and destroyed by the ACS "Manager" as 
they are needed by clients, but persistent servants (typi- 
cally, those devices closest to the hardware) can also be 
created at system start-up. Device configuration and some 
aspects of system configuration are implemented using a 
centralized database. 

2.4 Properties 

Devices in the control system have both properties and 
methods. Since properties, like devices, are themselves 
CORBA objects, clients may get references to properties 
or devices that are physically located on any computer on 
the network. Using features of ACS, properties may have 
monitors or alarms attached to them, or a client may simply 
poll a property at will. 

2.5 Timing 

The ALMA time system will establish synchronized 
switching cycles and mode changes, and provide time- 
stamping for the resulting measurements across the en- 
tire instrument, including the central building and the geo- 
graphically dispersed antennas. Additionally, the time sys- 
tem must be accurately related to external measures of time 
to correctly determine the position of astronomical objects 
of interest. The fundamental time system of the interfer- 
ometer is TAI time maintained in a central master clock. 

While most devices do not have precise timing require- 
ments, a timing pulse with a 48 ms period is distributed 
throughout the entire array to provide a time basis for those 
devices that do have more precise timing requirements. For 
such a device, the control software must arrange to have 
monitor and control commands sent to the device in pre- 
cisely defined windows within the 48 ms timing period. 
Time-tagged commands from the center must be transmit- 
ted sufficiently early to account for the non-determinism 
in the network and general-purpose ACC. The slave clocks 
are given the array time of a particular timing event, and 
thereafter maintain time by counting timing events. 

Some of the relevant time scales in the control system 
are as follows. 

• 2 ms: The shortest time-scale at which any device 
will require interaction. Shorter time-scales are al- 
ways handled by hardware. 

• 16 ms: Fastest correlator dump time. 

• 48 ms: The period of the pervasive timing event sent 
to all hardware with precise timing requirements. 

• Is: The fastest time-scale for observational changes, 
e.g., source changes or changes in correlator setup. 

• >1 s: Most devices will be monitored or controlled at 
rates slower than 1 Hz, often much slower (300 s). 



3 EXAMPLE DEVICE: FINE TUNING 
SYNTHESIZER 



non-linearities in the phase function, and to control quanti- 
zation errors in the phase generation. 



The fine tuning synthesizer (FTS) is a low-level device that 
is a component of local oscillators throughout the array. It 
provides the fine adjustment of the local oscillator phase 
and frequency (for the purposes of fringe tracking), and 
phase switching capabilities (used to remove spurious sig- 
nals and for sideband separation). Like most devices, the 
FTS hardware is monitored or controlled via the antenna- 
wide CAN bus. 

To present an example of the execution of TICS, a short 
description of some of the properties of the FTS is given 
here. 

3. 1 Timing 

The FTS implements several timing event associated com- 
mands. All of the functionality of the FTS depends upon 
synchronization with the pervasive timing event. Effective 
phase switching requires synchronization between anten- 
nas at the start of the phase switching function. Fringe 
tracking depends upon tracking and pointing information to 
achieve the desired phase output at the proper time; there- 
fore, updates to the phase function must remain synchro- 
nized with the timing event. 

The time scales of importance to the FTS are the follow- 
ing: 

• 250 /is: shortest phase switching interval 

• 16 ms: fast phase switching period, shortest slow 
phase switching interval 

• 48 ms: phase chirp modulation update rate 

• ~1 s: slow phase switching period 

• ~10 s: fast switching calibration 

• ^100 s: fringe tracking frequency update. 

3.2 Properties 

Fringe tracking Local oscillators will be compound 
devices, each containing an FTS device. A command from 
a high-level device to a local oscillator device to set a 
frequency will occur at the array network level through 
CORBA. Such a command will occur whenever the astro- 
nomical source or receiving frequency is changed. 

The inputs required by the FTS for fringe tracking are 
all dynamic, depending upon factors such as the observing 
frequency and tracking information. A client of the FTS 
device, namely a local oscillator, will be responsible for 
setting these properties as necessary. On the other hand, 
the phase function needed by the FTS to provide accurate 
phase tracking services may be obtained by the local oscil- 
lator from a phase model server running on the ACC. 

The FTS device controller will send commands to the 
hardware on the CAN bus just prior to the timing event on 
which the changes are to take effect. After setting initial 
conditions, the FTS device may then update a phase chirp 
modulation parameter at the 20 5/6 Hz rate to adjust for 



Phase switching For phase switching, each FTS uses 
a four-valued step function with a minimum interval of 
250 /is between changes, and a period of 1 .024 s. The func- 
tions comprise a mutually orthogonal set, from which each 
antenna uses a single element over its "lifetime". There 
are in fact two, nested two-state switching cycles, which 
compose the overall 1.024 s cycle; however, the functions 
used by the two cycles are similar, differing only in scal- 
ing on the time axis, and a shift on the phase axis. The 
phase switching function to be used by a particular FTS 
may therefore be configured using a value from the con- 
figuration database, allowing the device controller to set its 
own phase switching function when it is instantiated. 

Because the rate of phase switching is faster than it is 
possible to accurately control from the ABM, the phase 
switching itself is implemented by the FTS hardware. The 
precision required of the phase switch times is ensured by 
an especially precise "version" of the 48 ms timing pulse 
that is received by the FTS hardware. 

4 TICS STATUS 

The first version of TICS (version 0.1) was released ear- 
lier this year, and the next release is scheduled to occur in 
February of next year. By mid-April of 2002, the first TI 
antenna will be ready for evaluation. TICS will support 
mount control and pointing tests by the time the antenna is 
delivered. As the antenna proceeds through the evaluation 
process, TICS will provide new capabilities to support re- 
quired testing. Concurrently, further integration with ACS 
and use of new ACS features (as they are developed) will 
also occur. 

5 REFERENCES 



[1] ALMA Web Site, ittp://www.alma.nrao.edu 

[2] G.Chiozzi, et al, "Common Software for the ALMA 
Project", ICALEPCS'01, San Jose, USA, 2001 



[3] CORBA Web Site, ittp://www.corba.org 



